Fremskynder denne siden med 50x
Jeg har sett alle disse studiene som viser hvordan en forbedring på 100 ms i sideinnlastingstid har en betydelig effekt på sidevisninger, konverteringsfrekvens osv., men jeg hadde faktisk aldri prøvd å optimalisere nettstedet mitt. Denne bloggen er en statisk Octopress-side, vert på GitHub-sider. Statiske nettsteder skal være raske, og GitHub Pages bruker Fastly, som skal være raskt, så alt skal være raskt, ikke sant?
Etter å ikke ha gjort dette før, visste jeg ikke hva jeg skulle gjøre. Men i en flott tale om hvordan internett fungerer, Dan Espeset foreslo å prøve nettsidetest; la oss gi det en sjanse.
Her er hva det viser med mitt nesten lager Octopress-oppsett. De eneste endringene jeg hadde gjort var å aktivere Google Analytics, knappene for sosiale medier nederst i innlegg, og legge til CSS-stil for tabeller (som som standard er ustilte og uleselige).
12 sekunder til første sidevisning! Hva skjedde? Jeg trodde statiske nettsteder skulle være raske. Den første byten kommer dit på mindre enn et halvt sekund, men siden begynner ikke å gjengi før 9 sekunder senere.
Ser ut som det første som skjer er at vi laster inn en haug med js og CSS. Ser vi på kilden, har vi alt dette js i source/_includes/head.html.
{% include google_analytics.html %}
js will stall page loading and rendering. What if we move the scripts to source/_includes/custom/after_footer.html?
That's a lot better! We've just saved about 4 seconds on load time and on time to start rendering.
Those script tags load modernizer, jquery, octopress.js, and some google analytics stuff. What is in this octopress.js anyway? It's mostly code to support stuff like embedding flash videos, delicious integration, and github repo integration. There are a few things that do get used for my site, but most of that code is dead weight.
Also, why are there multiple js files? Espeset also mentioned that connections are finite resources, and that we'll run out of simultaneous open connections if we have a bunch of different files. Let's strip out all of that unused js and combine the remaining js into a single file.
Mye bedre! Men vent et sekund. Hva trenger jeg js til? Så vidt jeg kan se, er det eneste siden min fortsatt bruker octopress's js for er slik at du kan skyve høyre sidefelt frem og tilbake ved å klikke på den, og jquery og modernizer er bare nødvendig for js som brukes i octopress. Jeg bruker aldri det, og ifølge in-page-analyse er det ingen andre som gjør det heller. La oss bli kvitt det.
Det endret ikke den totale lastetiden mye, men nettleseren begynte å gjengi raskere. Vi er i ferd med å ha nettstedet visuelt komplett etter 1,2 s, sammenlignet med 9,6 s i utgangspunktet - en 8 ganger forbedring.
Hva er igjen? Det er fortsatt noen js for twitter- og fb-widgetene nederst i hvert innlegg, men alle blir lastet inn etter at ting er gjengitt, så de påvirker egentlig ikke brukerens opplevelse, selv om de får "Load Time"-nummeret til å se dårlig ut.
Dette er et kakediagram over hvor mange byte av siden min som er viet til hver filtype. Tilsynelatende brukes mangfoldet av nyttelasten på fonter. Til tross for at referanseinnlegget mitt er et uvanlig bildetungt blogginnlegg, er fontene 43,8 % og bildene er en så liten prosentandel at webpagetest ikke engang viser tallet. Har ikke nettleseren min allerede noen standardfonter? Kan vi bare bruke dem?
Det viser seg at vi kan. Nettsiden er nå visuelt komplett på 0,9 s – en forbedring på 12 ganger. Forbedringen er ikke fullt så dramatisk for "Repeat View" - det er bare en forbedring på 8,6x der - men det er fortsatt ganske bra.
Det ene gjenværende "åpenbare" problemet er at overskriften laster to css-filer, hvorav den ene ikke er minifisert. Dette bruker opp to tilkoblinger og sender mer data enn nødvendig. Å forminske den andre css-filen og kombinere dem øker dette ytterligere.
Tiden for å fullføre visuelt er nå 0,7 s – en forbedring på 15,6 ganger. Og det er på en side som er uvanlig bildetung for nettstedet mitt.
På dette tidspunktet er det eneste som skjer før siden begynner å vises:, laste inn HTML-en, laste inn den css fil, og laster det gigantiske bildet (reliability.png).
Vi har allerede minifisert css, så det viktigste som gjenstår å gjøre er å gjøre gigantiske bilder bedre. Jeg har allerede løpt optipng -o7 -zm1-9 på alle bildene mine, men ImageOptim var i stand til å barbere av ytterligere 4 % av bildet, noe som ga en liten forbedring. På tvers av alle bildene i alle innleggene mine klarte ImageOptim å redusere bildene med ytterligere 20 % over optipng, men det hjalp ikke mye i dette tilfellet.
Jeg prøvde også å spesifisere størrelsen på bildet for å se om det ville la siden gjengi før bildet var ferdig nedlastet, men det resulterte ikke i mye forskjell.
Etter det kunne jeg ikke tenke meg noe annet å prøve, men webpagetest hadde noen nyttige forslag.
Tilsynelatende er serveren jeg er på treg (den får en D ved å sende den første byten etter den første forespørselen). Det anbefaler også å bufre statisk innhold, men når jeg ser på de individuelle forslagene, er de for det meste for widgets jeg ikke er vert for/kontrollerer. Jeg burde bruke et CDN, men Github Pages legger ikke innhold på et CDN for bare domener med mindre du bruker en DNS-aliaspost, og DNS-leverandøren min støtter ikke aliasposter. Det er to grunner til å slutte å servere fra Github Pages (eller kanskje én grunn til å flytte av Github Pages og én grunn til å få en annen DNS-leverandør), så jeg byttet til Cloudflare, som barberte over 100 ms fra tiden til første byte.
Merk at hvis du bruker Cloudflare for et statisk nettsted, vil du lage en "Sideregel" og aktivere "Cache Everything". Som standard bufrer ikke Cloudflare HTML, noe som er litt meningsløst på en statisk blogg som for det meste er HTML. Hvis du har gjort optimaliseringene her, vil du også unngå deres "Rocket Loader"-ting som prøver å laste js asynkront ved å laste blokkerende javascript. «Rocket Loader» er som AMP, ved at den kan få fart på store, oppblåste nettsteder, men er stor nok til at den bremser moderat optimaliserte nettsider.
Her er hva som skjedde etter at jeg i utgangspunktet aktiverte Cloudflare uten å innse at jeg trengte å lage en "sideregel".
Det er omtrent en dags trafikk i 2013. Opprinnelig serverte Cloudflare CSS-en min og omdirigerte til Github-sider for HTML. Så la jeg inn CSS-en min og Cloudflare gjorde bokstavelig talt ingenting. Totalt sett serverte Cloudflare 80 MB av 1 GB trafikk fordi det bare var caching av bilder og denne bloggen er relativt lett på bilder.
Jeg har ikke snakket om inlining CSS, men det er enkelt og gir en enorm hastighet ved første besøk siden det betyr at det bare kreves en tilkobling for å vise siden, i stedet for to sekvensielle tilkoblinger. Det er en ulempe ved fremtidige besøk siden det betyr at CSS må lastes ned på nytt for hver side, men siden mesteparten av trafikken min er fra folk som kjører over et enkelt blogginnlegg, som ikke klikker seg videre til noe annet, er det en netto gevinst. I _includes/head.html
{\% include all.css %}
no-wrap istedenfor nowrap) kutter ned gjenværende CSS med omtrent halvparten. Det gjenstår mye duplisering, og jeg forventer at CSS kan reduseres med ytterligere en faktor på 4, men det vil kreve å kunne CSS. Bare gjør disse tingene, kommer vi ned til .4s før nettsiden er visuelt komplett.
Det er en 10.9/.4 = 27.5 fold hastigheten opp. Effekten på mobil er mye mer dramatisk; der er det nærmere 50x.
Jeg er ikke sikker på hva jeg skal tenke om alt dette. På den ene siden er jeg glad for at jeg klarte å få en 25x-50x speedup på siden min. På den annen side forbinder jeg speedups i den størrelsesorden med portering av vanlig Ruby-kode til optimalisert C++, optimalisert C++ til en GPU, eller GPU til rask og skitten utforskende ASIC. Hvordan er det mulig at noen med null kjennskap til nettutvikling kan få den slags fart ved å se en presentasjon og deretter tulle rundt i 25 minutter? Jeg håpet å kanskje finne 100 ms slakk, men det viser seg at det ikke bare er 100 ms, eller til og med 1000 ms, men 10 000 ms slakk i et Octopress-oppsett. I følge en studie jeg har sett koster det å gå fra 1000ms til 3000ms 20 % av leserne og 50 % av klikkfrekvensene. Jeg har ikke sett en studie som ser på å gå fra 400 ms til 10 900 ms fordi ideen om at et nettsted vil være så tregt er så absurd at folk ikke engang ser på muligheten. Men mange nettsteder er så trege!
Oppdater
Jeg syntes det var for vanskelig å snuse rundt med å trimme ned den massive CSS-filen som følger med Octopress, så jeg fjernet all CSS og la deretter til noen linjer for å tillate en navigasjonslinje. Dette gjør nesten ingen forskjell på skrivebordsreferansen ovenfor, men det er en merkbar forbedring for trege tilkoblinger. Forskjellen er ganske dramatisk for 56k tilkoblinger så vel som tilkoblinger med høyt pakketap. Fra dagen jeg gjorde denne endringen, viser analysedataene mine en merkbar forbedring i engasjement og trafikk. Det er for mange ting som er forvirret her til å si hva som forårsaket denne endringen (ytelsesøkning, total mangel på styling osv.), men det er et par ting som er interessante med dette. For det første ser det ut til å vise at rådet om at det er veldig viktig å holde linjelengdene korte er feil siden, hvis det hadde en veldig stor innvirkning, ville det ha overveldet de andre endringene og resultert i redusert engasjement og ikke økt engasjement. For det andre, til tross for at Octopress-designet er mye brukt og hyllet (det ser ut til å ha vært det mest brukte bloggtemaet for programmerere da jeg startet bloggen min), ser det ut til å føre til at en blogg (eller i det minste denne bloggen) får mindre lesertall enn å bokstavelig talt ikke ha noen styling i det hele tatt. Å ikke ha noen styling er sikkert ikke optimalt, men det er noe litt morsomt med ingen styling som slår den på den tiden mest brukte bloggstylingen for programmerer, noe som betyr at den sannsynligvis også slår wordpress, svtble, blogspot, medium, etc., siden de har de fleste av de samme ingrediensene som Octopress.Ressurser
Dessverre er videoen av presentasjonen jeg refererer til begrenset RC-alums. Hvis du er en RC-alun, sjekk dette ut. Ellers er nettlesernettverk med høy ytelse flott, men mye lenger.Anerkjennelser
Takk til Leah Hanson, Daniel Espeset og Hugo Jobling for kommentarer/korrigeringer/diskusjon. Jeg er ikke en front-end person, så det kan hende jeg er helt ute av hvordan jeg ser på disse referansene. Hvis ja, vær så snill gi meg beskjed.Source link
